Mybells's Log

# 22. ai相关问题

# 1. AI 不会取代程序员，但会用 AI 的程序员会取代不用 AI 的程序员

这句话我拆成两层理解：AI 不会取代程序员（趋势判断），会用 AI 的程序员会取代不会用的（个人竞争力）。

# AI 为什么不会取代程序员？

  1. AI 缺乏业务理解与上下文：程序员的价值不只是写代码，而是理解业务目标、梳理需求、权衡取舍。AI 只能基于已有信息生成，无法对业务结果负责。
  2. 复杂架构需要人来决策：系统拆分、技术选型、扩展性、可维护性、团队协作这些"软能力"，AI 给不了确定答案，需要人的经验与判断。
  3. 责任与信任：代码出问题谁来负责？AI 不能背锅，也不能为线上事故负责。最终为代码质量和结果负责的一定是人。
  4. AI 有幻觉、会一本正经地出错：尤其在边界条件、安全、新特性上，AI 的输出必须人肉验证。
  5. 创造力与审美：产品设计、交互体验、创新方案，依赖人对用户和业务的理解。

# 为什么"会用 AI 的程序员"会取代"不会用 AI 的"？

  1. 效率差距：同样一天，会用 AI 的人能完成 2~3 倍的工作量——生成骨架、写测试、改 bug、查文档都快得多。
  2. 质量工具化：把 AI 当"结对程序员 + 代码审查员"，能提前发现边界、空值、安全漏洞，把质量关卡前置。
  3. 知识平权：AI 抹平了信息差，会用的人把精力从"怎么写"解放出来，聚焦在"做什么、为什么"上。

# 一句话总结

AI 是放大器而不是替代者：会用 AI 的工程师，把时间花在思考和决策上；不会用的，时间都耗在重复劳动上。所以我的策略是——把 AI 当同事、不当拐杖：让它做执行和初稿，我做判断和兜底。

ai

# 2. 什么是 RAG？

RAG（Retrieval-Augmented Generation，检索增强生成）：让大模型在生成答案时，先从外部知识库检索相关信息，再基于这些信息回答问题。

我把 RAG 分为两个阶段理解：

  1. 离线索引阶段：将私有知识库的文档切块、向量化，存入向量数据库。
  2. 在线查询阶段：将用户问题向量化，从向量数据库中检索最相关的 Top-K 文本块，拼接成 Prompt 后调用 LLM 生成答案。

相比微调，RAG 的优势：知识更新成本低、可溯源、幻觉少。

rag

# 3. 如何使用 AI 工具？

AI 不是替代我思考，而是放大我的产出效率。我的核心原则是：AI 做执行、我做决策；AI 生成、我 review；最终质量和结果由我负责。下面是我在项目中沉淀的一套 AI 辅助开发工作流：

# ① 前置：制定 Skills，统一规范

  1. 提前把团队/项目的开发规范、技术栈、组件库约定、命名规范沉淀成 Skills（能力说明）给 AI，让 AI 一开始就"懂规矩"，避免每次生成都要重复纠正。
  2. 把高频组件、工具函数、公共样式整理成可复用上下文，AI 生成代码时优先复用，保证代码风格和团队一致。

目的：让 AI 的输出天然符合团队规范，从源头减少返工。

# ② 需求 → 开发方案（AI 是军师，我做决策）

  1. 拿到需求后先自己读透：梳理核心目标、关键路径、边界条件、疑问点。
  2. 把需求文档发给 AI，让它输出开发方案 + 开发步骤：模块拆分、技术选型、数据结构、接口设计、风险点、排期。
  3. 人工评审方案：重点评估可执行性、有没有缺漏、边界是否覆盖、有没有过度设计，有问题先改方案再开发。

关键：方案阶段 AI 可以发散，但最终拍板的一定是我，避免被 AI 带偏方向。

# ③ 开发：架构生成 + 按步骤推进 + 逐段 review

  1. 先让 AI 生成项目骨架、目录结构、核心类型/接口定义，再按方案拆解的步骤逐步开发，每完成一步确认结果再继续。
  2. 结合测试思维：先让 AI 写关键用例/单元测试，再实现功能，保证可验证。
  3. 每段 AI 代码我都会过一遍，重点检查：逻辑正确性、异常处理、安全漏洞（XSS/SQL 注入/越权）、性能、可维护性，不盲信。

关键：AI 写代码快，但"能跑"不等于"正确"，核心逻辑和安全红线必须人肉把关。

# ④ 设计稿还原：Figma MCP + mock 数据

  1. 通过 Figma MCP 把设计稿/组件节点链接给 AI，按设计稿的尺寸、间距、颜色、圆角、交互精确生成代码。
  2. 同步生成 mock 数据文件，保证后端未就绪时页面也能先跑通。
  3. 细节校对：逐屏比对设计稿，做到设计稿什么样、页面就什么样，同时保证功能与需求一致，不为了还原而牺牲交互。

# ⑤ 前后台联调：接口文档 MCP

  1. 把后端接口文档（Swagger/OpenAPI）通过 MCP 链接给 AI，让它按真实接口的字段、类型、命名修改前端代码，避免手抄字段出错。
  2. 重点覆盖：请求参数校验、响应空值/异常态、loading/error 状态、字段缺失时的兜底逻辑。

# ⑥ 自测 + BugFix（AI 解决，我理解根因）

  1. 自测覆盖：功能路径、边界输入、异常场景、兼容性（浏览器/分辨率）、弱网。
  2. 发现 bug 直接把报错栈、复现路径、期望行为喂给 AI 定位修复，效率很高；但每个修复我都会理解根因后再合入，不盲信 AI 的 patch。
  3. 全部通过后提测；提测前再跑一遍关键回归 + lint/类型检查。

# 我的三条底线（体现思辨）

  1. AI 生成 ≠ 可靠：AI 写的代码必须 review + 自测，安全与核心逻辑绝不裸奔。
  2. AI 不背锅：出了问题责任在我，所以架构选型、关键决策、上线前检查一定人肉兜底。
  3. 持续沉淀：把踩过的坑、有效的提示词、团队规范不断更新进 Skills，让 AI 越用越顺手。

一句话总结：我的 AI 工作流是 "规范前置 → AI 提方案 → 人审拍板 → 分步生成 → 全程 review → 自测兜底"，AI 负责速度和细节，我负责方向和质量。

← 23. 性能优化方法 →